Skelebrator is designed to skeletonize a single scenario at a time. Specifically, skelebrator modifies information in the set of alternatives (topological, demand, physical etc.) that are referred to by the currently selected scenario. It follows that any other scenarios that refer to these alternatives in some way can also potentially be modified by skeletonization but most likely in an undesirable and inconsistent way, since skeletonization only works on the data in the alternatives referenced by the currently active scenario.

For example, a second scenario that references all the same alternatives as the scenario being skeletonized except for, say, the demand alternative, will itself be seemingly skeletonized (its topological and physical alternatives, etc. are modified) except that the values of demands in its local demand records have no way of being factored into the skeletonization process. Due to this, demands may actually be lost since pipes that were deleted (e.g., dead ends) did not have their local demands relocated upstream. Relocated demands will represent the result of merging the demands in the parent alternative and not those of the child alternative where local records are present.

Due to the behavior of skeletonization with respect to scenarios and alternatives and to save possible confusion after skeletonization, it is very strongly recommended that you eliminate all other scenarios (other than the one to be skeletonized) from the model prior to skeletonization. Some exceptions, however, exist to this recommendation and may provide some additional flexibility to those users who have a strong desire to skeletonize multiple scenarios. In general, it is strongly recommended that multiple scenario skeletonization be avoided.

A multiple scenario model can be successfully skeletonized only if all of the following conditions are met:

• All scenarios all belong to the same parent-child hierarchy
• The scenario being selected for skeletonization must contain only parent (base) alternatives
• All elements that reference local records in any child alternative are protected from skeletonization.

As a simple example, consider a model with two scenarios, Base and Fire Flow. The Base scenario references a set of parent (base) alternatives, and the Fire Flow scenario references all the same alternatives, except for the demand alternative, where it references a child alternative of the Base scenario demand alternative, with local records at junctions A-90 and A-100 which are to model the additional flow at the fire flow junctions. This model meets all of the above 3 conditions and thus skeletonization of this model can be conducted successfully for all scenarios in the model, but only if all of the following skeletonization rules are adhered to:

• The Base scenario is always selected for skeletonization
• The elements associated with local demand records (i.e., junctions A-90 and A-100 in our example) are protected from skeletonization using the Skelebrator element protection feature.

The reason the base scenario (a) must be selected for skeletonization is so that only parent (base) alternatives are modified by skeletonization. This is so that changes made to alternatives propagate down the parent-child hierarchy. If skeletonization was to occur on a scenario that referenced child alternatives, then the changes made to the scenario will not propagate back up the parent-child hierarchy and would result in incorrect results.

The reason for the element protections (b) is to limit the scope of skeletonization to the data common to both scenarios. That is, any model elements that possess any local records in any referenced child alternative are excluded from the skeletonization since the differences in properties between the child and parent alternatives cannot be resolved in a skeletonization process that acts for all intents and purposes on a single scenario. This idiom can be extended to other alternative types besides the demand alternative.